第2章 パッケージ原則 ひさてるさんのツイート
同じ OOP 系の啓蒙話でも、長期のチーム仕事になると OOP 関係なく必ず出てくるのがパッケージ原則の問題なので、SOLID までは選択の余地ないから絶対やっとけ。デザインパターンは選択の余地があるから、知ってたとしてもすぐには使うな。持ち込むべきものだけ持ってこい。#ちょうぜつ本 の境界線です
単一責任の原則のパッケージ版って、 CCP よりどっちかっていうと CRP じゃないの? 全再利用なんだぞ 2 つも 3 つも責務兼ねた神クラスやめろって意味で。CCP はなんか「なんで RGB と A が別のオブジェクトなん? RGBA じゃないの?」ってほう。こっちは 1 に満たないのを 1 にして「単一」になって感じ
なるほどコミットも、分けるべきとまとめるべきのポイントはやっぱり、Common Closure Principle (CCP) と Common Reuse Principle (CRP) の関係と同じってことだ
疎結合がよいというスローガンは、何も考えずに密結合しちゃう人が多すぎる偏りからきてるんだけど、本当は CCP と同時に CRP もあって、独立した交換部品の単位でパッケージにまとめるということは、その内部を密結合にするのとパッケージ境界を疎結合にするのの表裏一体なんだよなぁという思い
ひとつのコミットで変更がソースルート直下フォルダのいたるところに散るつらみ、CCPうまくいってないって話ですっと言えればと思って、そういうの1階層でいいから特定のフォルダ以下にまとまってくれたら、どの系の機能の変更かすぐわかるし、関係ないとこにちらっとはみ出してたらなんでよって気づく
変更の複雑さがフォルダの中に隠蔽されるとこんど、ADPが守られてないと変更待ちの3すくみみたいな硬直が生まれて、突破するには3パッケージ同時に変更になって、やい閉じてないじゃんってなるし、変更影響3倍で進まないしなので、循環依存は感染病。持たない作らない持ち込ませない
オニオンは具体的なコンポーネント配置を決めていて、クリーンはオニオンを含めた設計の抽象モデル。DIP を使った SDP と SAP のことと、ドメインとインフラのギャップを埋める変換レイヤーがアプリケーションだという、構造の特徴を語った、アーキテクチャのデザパタと理解している